• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The object of the present invention is to provide a bridge program for achieving a common use of the interface between a number of modules with different configurations and a hardware model obtained by modeling hardware with software. A bridge program allows a computer to execute: an acquisition step that obtains an operating structure delivered by the module to the hardware model; a conversion step that converts the interface of the module into a common interface corresponding to the hardware model; and a recognition step which obtains the operation instruction obtained by the acquisition step via the common interface in which the interface of the module is converted by the conversion step, which recognizes to which hardware model the operation instruction has been delivered, and which executes the operation instruction to the recognized hardware model.
    公开号:BE1018147A5
    申请号:E2008/0272
    申请日:2008-05-15
    公开日:2010-06-01
    发明作者:Shogo Ishi；Toshiyuki Ohno；Akira Ishitsuka
    申请人:Toshiba Kk；Toshiba Solutions Corp；
    IPC主号:
    专利说明:

    BRIDGE PROGRAM, BRIDGE METHOD, AND SIMULATOR Background of the invention 1. Field of the invention
    The present invention relates to a bridge program and a bridge method that converts a specific interface for a number of modules with different configurations into a common interface to enable the connection between the modules and a hardware model, and to a simulator that runs the bridge program.
    2. Description of the prior art
    In a development process of a product consisting of a CPU and peripheral hardware, a simulator is used to verify the operation of part of the components or of all components included in the product.
    In most cases, the configurations between simulators differ depending on the target product to be verified. In one simulator, a CPU model for simulating a CPU function is implemented by hardware and a hardware model for simulating the function of the peripheral hardware that is different from the hardware modeled by the CPU model is implemented by software on a computer. In another simulator, both the CPU model and the hardware model are implemented by software on a computer.
    Even when configurations differ between Simulators, as described above, there is often a situation where the same function is implemented on the hardware model although the configurations of the CPU models differ from each other. In such a case it is desirable to reuse the existing hardware model as much as possible to reduce the development cost and development time of the product and in terms of software quality retention and efficient use of resources.
    As a state of the art for the present invention, a system simulator is known that integrally verifies a program and hardware of an electronic device, using a microcomputer (e.g., Patent Document 1: Published Japanese Patent Application with Publication No. 2000-35898 ). This system simulator includes: a hardware simulator that uses software to verify the hardware based on the program; a virtual model simulator that uses software to process a command from the program relative to the hardware in an equivalent manner to the hardware; and a CPU model simulator that uses software to verify the program while appropriately using the hardware simulator or virtual model simulator output.
    However, if the configurations of the CPU models differ, for example between two simulators, the existing hardware model that matches the interface of one CPU model does not match the interface of another CPU model, so that it is necessary to design a new hardware model to match the interface of the hardware model with the interface of the CPU model. Consequently, no reduction in product development cost and development time, no quality retention of the hardware model, and no efficient use of resources can be achieved.
    Patent document 1 neither discloses nor suggests a mechanism for eliminating the difference of interfaces that is caused when configurations differ among themselves between simulators as described above.
    Furthermore, in a chapter written by Gamma et al. Entitled "Design Patterns: Elements of reusable object-oriented software", pages 139-161, a method is described for converting the interface of a class into another interface that the customer expected.
    Summary of the invention
    The present invention has been made to solve the above problem and the object of the invention is to provide a bridge program and a bridge method with which a common use of the interface between a number of CPU models with different configurations and a hardware model can be achieved and to provide a simulator that runs the bridge program.
    To solve the problem above, according to a first aspect of the invention, a bridging program is provided whereby a computer has a number of modules with mutually different configurations implemented with software or hardware and at least one hardware model obtained by modulating hardware can connect to software, whereby the program allows the computer to execute: an acquisition step that obtains an operating instruction delivered by the module to the hardware model; a conversion step which converts the interface of the module into a first interface corresponding to the hardware model; a recognition step which obtains the operation instruction obtained during the acquisition step via the first interface in which the interface of the module is converted by the conversion step, and which recognizes to which hardware model the operation instruction has been delivered, and which executes the operation instruction to the recognized hardware model.
    Preferred embodiments are described in claims 2-4 and 9-11.
    An execution of the bridging program further allows the computer to execute: a first execution step that obtains an operating status of the hardware model that has been executed in response to the operating instruction of the hardware model, and which outputs the operating status via the first interface, wherein the interface of the module is converted by the conversion step and a second output step which converts the first interface into the interface of the module and which outputs the operating status that was executed during the first output step to the module via the interface of the module in which the first interface is converted .
    In an embodiment of the bridge program according to the present invention, the conversion step performs the interface conversion based on the information regarding the module.
    In an embodiment of the bridge program according to the present invention, the recognition step recognizes to which hardware model the operating instruction is delivered based on information regarding the hardware model.
    To solve the above problem, a second method of the invention further provides a bridge method that connects a plurality of modules with mutually different configurations implemented by software or hardware to at least one hardware model obtained by modeling hardware with software, comprising: an acquisition step that obtains an operating instruction delivered by the module to the hardware model; a conversion step which converts the interface of the module into a first interface corresponding to the hardware model; a recognition step which obtains the operation instruction obtained by the acquisition step via the first interface in which the interface of the module is converted by the conversion step, which recognizes to which hardware model the operation instruction is delivered and which executes the operation instruction to the recognized hardware model.
    Preferred embodiments are described in claims 6-11.
    An embodiment of the bridge method according to the present invention further comprises: first output step that obtains an operating status of the hardware model that is executed in response to the operating instruction of the hardware model, and which outputs the operating status via the first interface, wherein the interface of the module is converted by the conversion step and a second output step which converts the first interface to the module's interface and which outputs the operation status that was performed during the first output step to the module via the interface of the module in which the first interface is converted.
    In an embodiment of the bridge method according to the present invention, the conversion step performs the interface conversion based on the information regarding the module.
    In an embodiment of the bridge method according to the present invention, the recognition step recognizes to which hardware model the operating instruction is delivered based on information regarding the hardware model.
    To solve the above problem, a third aspect of the present invention further provides a simulator comprising: a plurality of modules with mutually different configurations implemented by software or hardware; at least one hardware model obtained by modulating hardware with software; an acquisition section that obtains an operating instruction delivered by the module to the hardware model; a conversion section that converts the interface of the module into a first interface corresponding to the hardware model; a recognition section that obtains the work instruction obtained by the acquisition section via the first interface in which the interface of the module is converted by the conversion section, and which recognizes in which hardware model the operation instruction is delivered, and which executes the operation instruction to the recognized hardware model.
    Preferred embodiments are described in claims 13-19.
    An embodiment of the simulator according to the present invention further comprises: a first output section which obtains an operating status of the hardware model executed in response to the operating instruction of the hardware model and which outputs the operating status via the first interface in which the interface of the module is converted, through the conversion section; and a second output section which converts the first interface into the interface of the module and which outputs the operating status output from the first output section to the module via the interface of the module in which the first interface is converted.
    In an embodiment of the simulator according to the present invention, the conversion section performs the conversion in the first interface based on information regarding the module.
    In an embodiment of the simulator according to the present invention, the recognition section recognizes to which hardware model the operating instruction is delivered based on information regarding the hardware model.
    According to the present invention, an operating instruction can be delivered from a number of modules with different configurations implemented by software or hardware to a hardware model obtained by modeling hardware with software.
    BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a view showing a configuration of a simulator and an embodiment of the present invention; FIG. 2 is a flow chart showing the process flow of the operating instruction from a CPU model section to a peripheral hardware model section in the embodiment of the present invention; and FIG. 3 is a flow chart showing the process steps for outputting work output information from the peripheral hardware model section 20 to the CPU model section 10.
    Detailed description of the preferred embodiments
    An embodiment of the present invention will be described with reference to the accompanying drawings. A configuration of a simulator according to the present embodiment is shown in FIG. 1.
    A simulator 50 includes a CPU model section 10, a peripheral hardware model section 20, a bridge 1 for negotiating mutual access between the CPU model section 10 and peripheral hardware model section 20, and a storage section 30.
    The CPU model section 10 includes CPU models (modules). Each CPU model has at least one function as a CPU, and further has a function like OS (operating system) that runs on the CPU and a function as an application that runs on the OS.
    In the present embodiment, a CPU model 100A consists of a CPU (represented as "CPU (SW)" in Fig. 1) configured by software to stimulate the CPU function and an OS and application running on the CPU. . A CPU model 100B has a configuration implemented by an OS emulator (software) including the CPU function. A CPU model 100C consists of a minimum hardware configuration (CPU (represented as "CPU (HW)" in Fig. 1)) required to run an OS, a memory (RAM or ROM, etc.), and an OS and application running on the CPU. The CPU model 100C comprises a PCI card, which is connected to the minimum hardware configuration via a bus.
    Although the hardware configuration of the simulator 50 is achieved through the PCI connection between the CPU model 100C and the PC, it is only required for the simulator 50 to have the configuration as described in the present embodiment, in which the functions such as the CPU model and hardware model are included and in which data can be exchanged between the CPU model and hardware model.
    The peripheral hardware model section 20 is obtained by implementing, by software, the function of peripheral hardware that is not included in the CPU model section 10 and which includes hardware models (hardware model 200A, hardware model 200B, etc.) obtained by converting the respective peripheral hardware components into a software configuration.
    The storage section 30 stores in advance CPU model definition information as information regarding the respective CPU models in the CPU model section 10. Further, the storage section 30 stores in advance hardware model definition as information regarding respective hardware models in the peripheral hardware model section 20 .
    The bridge 1 negotiates mutual access between the CPU model section 10 and the peripheral hardware model section 20.
    The bridge 1 in the present embodiment comprises an interface section 2 (I / F section); an interface conversion section 3 (I / F conversion section); and a hardware model recognition section 4.
    The interface section 2 enables the connection between the specific interface of each CPU model in the CPU model section 10 and bridge 1, and obtains an operating instruction for each hardware model of the peripheral hardware model section 20 of each CPU model.
    The interface section 2 includes connection sections. Each of the connection sections is connected to a corresponding CPU model. In the present embodiment, a connection section 120A is connected to the CPU model 100A, connection section 120B to the CPU model 100B, and connection section 120C to the CPU model 100C. The connection section 120C is connected to a CPU model (CPU model 100C) consisting of hardware using a device driver of a PCI card.
    The interface section 2 divides the memory zone of a memory of the simulator 50 of each CPU model in advance and assigns the obtained memory zone to each connection section. Each connection section ensures that the allocated memory zone functions as a register of a corresponding CPU model. While obtaining the operating instruction of each CPU model, each connection section stores the operating instruction in the register.
    Furthermore, the interface section 2 negotiates information that is output from each hardware model of the peripheral hardware model section 20 and every CPU model.
    The interface conversion section 3 converts the specific interfaces, which are connected to the interface section 2, which have mutually different configurations in a common interface (first interface) corresponding to the peripheral hardware model section 20 based on the CPU model defintion information stored in the storage section 30. The interface conversion section 3 comprises individual interface conversion sections (individual I / F conversion sections) corresponding to the respective connection sections of the interface section 2, each of which performs a conversion into the common interface.
    The CPU model definition information defines the correspondence between identification information (CPU model ID) of each CPU model of the CPU model section 10, each connection section of the interface section 2, and each individual interface conversion section. This means that the interface conversion section 3 detects which connection section has received the operation instruction so as to identify the corresponding CPU model ID and identify the corresponding individual interface conversion section based on the CPU model definition information and causes the identified individual interface conversion section to carry out the conversion. The CPU model definition information may define correspondence between the CPU model ID, each memory zone corresponding to each connection section, and the individual interface conversion sections. In this case, the interface conversion section 3 must detect to which memory zone access has been granted.
    The individual interface conversion section achieves a conversion to the common interface by means of a file transfer or API (Application Program Interface). Furthermore, at least identification information (CPU model ID) of the CPU model that is a transmission source of the operating instruction and identification information (operating instruction ID) of the operating instruction are added to the operating instruction exchanged via the common interface. The operation instruction ID is defined in the interface conversion section 3 and is added based on the operation instruction obtained by each connection section of the interface section 2.
    In the present embodiment, the individual interface conversion section 13OA corresponds to the connection section 120A, the individual interface conversion section 130B corresponds to the connection section 120B, and the individual interface conversion section 13OC corresponds to the connection section 12OC.
    The interface conversion section 3 also performs a conversion from the common interface to the specific interface of each CPU model to negotiate information output from the hardware model to the CPU model.
    The hardware model recognition section 4 obtains the operation instruction obtained from the interface section 2 via the common interface in which the specific interface is converted by the interface conversion section 3, recognizes in which hardware model the obtained operation instruction was delivered based on the hardware model definition information stored in the storage section 30, and executes the operating instruction to the intended hardware model.
    The hardware model definition information defines the correspondence between the operation instruction ID, the hardware model, and the operation of the hardware model. This means that the hardware model recognition section 4 compares the operation instruction ID included in the operation instruction data obtained through the common interface with the hardware model definition information to thereby identify the hardware model and its operation, and then the operation of executes the identified intended hardware model. Furthermore, the hardware model recognition section 4 maintains the CPU model ID included in the operating instruction data.
    The hardware model recognition section 4 obtains information (work output information) such as an operating status of the hardware model and outputs the obtained work output information to the interface conversion section 3 via the common interface.
    The process steps performed in the simulator 50 will be described below. First, the process flow of the operating instruction from the CPU model section 10 to the peripheral hardware model section 20 will be described with reference to the flow chart of FIG. 2. Although in this example the operating instruction is delivered from the CPU model 100A of the CPU model section 10 to the hardware model 200A of the peripheral hardware model section 20, the correspondence between the CPU model and the hardware model can be arbitrarily swapped.
    The interface section 2 obtains the operation instruction from the CPU model 100A through the connection section 120A (step 51).
    The interface conversion section 3 selects the individual interface conversion section that performs the conversion based on the CPU model definition information (step 52). In this case, the individual interface conversion section 130A is selected.
    The individual interface conversion section 130A converts the specific interface of the CPU model 100A to the common interface (step S3).
    The hardware model recognition section 4 obtains the operation instruction from the individual interface conversion section 130A (interface conversion section 3) via the common interface. Furthermore, the hardware model recognition section 4 recognizes to which hardware model of the peripheral hardware model section 20 the delivered operation instruction was delivered based on the hardware model definition information, and the hardware model recognition section 4 outputs the operation instruction to the intended hardware model (step S4). In this case, the hardware model recognition section 4 recognizes that the operation instruction was delivered to the hardware model 200A and outputs the operation instruction to the hardware model 200A.
    Now, the process steps for outputting the work output information (information such as on operating status of the hardware model performed in response to the operating instruction) from the peripheral hardware model section 20 to the CPU model section 10 will be described with reference to FIG. 3. Although in this example the work output information is delivered from the hardware model 200A of the peripheral hardware model section 20 to the CPU model 100A of the CPU model section 10, the correspondence between the CPU model and the hardware model can be arbitrarily swapped as in the case of the aforementioned operating instruction process steps.
    The hardware model 200A outputs the work output information for the received operating instruction to the hardware model recognition section 4 (step S11).
    The hardware model recognition section 4 obtains the work output information, adds the CPU model ID (identification information indicating to which CPU model the work output information is sent) to the work output information, and outputs the resulting work output information to the interface conversion section 3 via the common interface (step S12).
    The interface conversion section 3 refers to the CPU model ID to output the work output information to the individual interface conversion section corresponding to the intended CPU model (step S13). In this case, the work output information is output to the individual interface conversion section 130A.
    Upon receipt of the work output information, the individual interface conversion section 130A converts the common interface to the specific interface of each CPU model. Further, the individual interface conversion section 130A outputs the work output information to the CPU model of the CPU model section via the corresponding connection section of the interface section 2 (step S14). In this case, the work output information is output to the CPU model 100A via the connection section 120A.
    When outputting the work output information from the connection section 12OA to the CPU model 100A, a value containing the work output information is stored in a predetermined register in the memory zone assigned to the connection section 12OA. Thereafter, when access is made to the predetermined register, an interruption of the CPU model 100A occurs, the CPU model 100A obtaining the work output information from the predetermined register.
    As described above, the bridge 1 absorbs the difference in the connection configurations of the interfaces between the CPU model and the hardware model and provides a common interface to the hardware model, thereby allowing common use of the hardware model.
    Furthermore, the addition of a bridge function is easier to achieve than the development of a new hardware model, so that it is possible to form a simulation environment in a short time.
    Furthermore, the reuse of the existing hardware model is made possible in such a way that the quality of the hardware model can be improved while the development cost and development time thereof are reduced.
    An acquisition section corresponds to the interface section 2 in the embodiment, and a conversion section corresponds to the interface conversion section 3 in the embodiment. A recognition section and a first execution section correspond to the hardware model recognition section 4 in the embodiment, and a second execution section corresponds to the interface section 2 and interface conversion section 3.
    Although the module has been described as a CPU model in the present embodiment, any module can be used that can execute the operating instruction to the hardware model.
    Although the bridge program is installed in advance in the simulator of the present embodiment, the bridge program of the present invention can be stored in a storage medium. The said storage medium here encompasses all media that can be read and executed by a computer and a simulator. Examples of such media include a media removable from the simulator such as a magnetic tape, a magnetic disk (floppy disk, hard disk drive, etc.), an optical disk (CD-ROM, DVD disk, etc.), a magneto optical disk (MO, etc.), a flash memory, or similar to a medium that can be sent via a network.
    权利要求:
    Claims (19)
    [1]
    A bridge program through which a computer can have a number of modules (100A-C-) with mutually different configurations implemented by software or hardware, and at least one hardware model (200A-D) obtained by modeling hardware with software connecting, the program allowing the computer to perform the following steps: an acquisition step that obtains an operating instruction delivered by the module to a hardware model (51); a conversion step which converts the interface of the module to a first interface corresponding to the hardware model (53); and a recognition step which obtains the operation instruction obtained by the acquisition step via the first interface in which the interface of the module is converted by the conversion step, which recognizes to which hardware model the operation instruction has been delivered, and which executes the operation instruction to the recognized hardware model (54) .
    [2]
    A bridging program according to claim 1 that allows the computer to execute: a first output step that obtains an operating status of the hardware model executed in response to the operating instruction of the hardware model, and which outputs the operating status via the first interface in which the interface of the module has been converted by the conversion step; and a second output step which converts the first interface into the interface of the module and which outputs the operating status performed by the first output step to the module via the interface of the module in which the first interface is converted.
    [3]
    The bridge program of claim 1, wherein the conversion step performs the conversion in the first interface based on information regarding the module.
    [4]
    The bridge program of claim 1, wherein the recognition step recognizes to which hardware model the operating instruction is delivered based on information regarding the hardware model.
    [5]
    A bridge method that connects a number of modules with mutually different configurations implemented by software or hardware and at least one hardware model obtained by modeling hardware with software, comprising: an acquisition step that delivers an operating instruction delivered by the module to a hardware model; a conversion step that converts the interface of the module into a first interface corresponding to the hardware model; and a recognition step which obtains the operation instruction obtained by the acquisition step via the first interface in which the interface of the module is converted by the conversion step, which recognizes to which hardware model the operation instruction has been delivered, and which executes the operation instruction to the recognized hardware model.
    [6]
    A bridge method according to claim 5 comprising: a first output step that obtains an operating status of the hardware model executed in response to the operating instruction of the hardware model, and which outputs the operating status via the first interface in which the interface is converted by the conversion step; and a second output step which converts the first interface into the interface of the module and which outputs the operating status performed by the first output step to the interface of the module in which the first interface is converted.
    [7]
    A bridge method according to claim 5, wherein the conversion step performs the conversion in the first interface based on information regarding the module.
    [8]
    A bridging method according to claim 5, wherein the recognition step recognizes to which hardware model the operating instruction is delivered based on information regarding the hardware model.
    [9]
    Bridge program according to any of claims 1-4 or bridge method according to any of claims 5-8, wherein the or each module is an CPU model comprising an CPU, an OS and an application.
    [10]
    A bridging program as claimed in any one of claims 1-4 or a bridging method as claimed in any one of claims 5-8, wherein the or each module is a CPU model comprising an OS emulator and an application.
    [11]
    A bridging program according to any one of claims 1-4 or a bridging method according to any one of claims 5-8, wherein the at least one hardware model is obtained by converting respective peripheral hardware components into a software configuration.
    [12]
    A simulator comprising: a number of modules (100A-C) with mutually different configurations implemented by software or hardware; at least one hardware model (200A-D) obtained by modeling hardware with software; an acquisition section (2) that obtains an operating instruction delivered from the module to the hardware model; a conversion section (3) that converts the interface of the module into a first interface corresponding to the hardware model; and a recognition section (4) which obtains the operation instruction obtained by the acquisition section via the first interface in which the interface of the module is converted by the conversion section, and which recognizes to which hardware model the operation instruction has been delivered, and which outputs the operation instruction to the recognized hardware model.
    [13]
    A simulator according to claim 12, comprising: a first output section that outputs an operating status of the hardware model that is executed in response to the operating instruction of the hardware model, and which outputs the operating status via the first interface in which the interface of the module is converted by the conversion section; and a second output section which converts the first interface into the interface of the module and which outputs the operation status output from the first output section to the module via the interface of the module into which the first interface is converted.
    [14]
    The simulator of claim 12, wherein the conversion section performs the conversion in the first interface based on information regarding the module.
    [15]
    The simulator of claim 12, wherein the recognition section recognizes to which hardware model the operating instruction has been delivered based on information regarding the hardware model.
    [16]
    A simulator according to any of claims 12-15, wherein a CPU section definition information storage section (30) is provided, which CPU model definition information is the correspondence between identification information of each CPU model, of the acquisition section ( 2) and of the conversion section (3), wherein the conversion section (3) is arranged to detect which acquisition section has obtained the operation instruction so as to identify the corresponding CPU model and identify the corresponding conversion section based on the CPU model definition information.
    [17]
    A simulator according to any of claims 12-16, wherein the conversion section is arranged to achieve a conversion by means of a file transfer or API (Application Program Interface).
    [18]
    A simulator according to any of claims 12-17, wherein the conversion section (3) is arranged to define an operation instruction identification, which operation instruction identification information is added to the operation instruction together with CPU model identification information.
    [19]
    A simulator according to any of claims 12-18, wherein a storage section is provided for hardware model definition information that defines the correspondence between an operating instruction identification, the hardware model, and the operation of the hardware model, the recognition section (4) being arranged to compare the operating instruction identification included in the operating instruction with the hardware model definition information to thereby identify the hardware model and its operation.
    类似技术:
    公开号 | 公开日 | 专利标题
    Sinnema et al.2004|Covamof: A framework for modeling variability in software product families
    US8196138B2|2012-06-05|Method and system for migrating virtual machines between hypervisors
    US7571082B2|2009-08-04|Common component modeling
    US8561063B2|2013-10-15|Platform independent replication using virtual machines
    US10922654B2|2021-02-16|Software assurance and trust in a distributed delivery environment
    EP2245532B1|2020-12-02|Method and apparatus for generating virtual software platform based on component model and validating software platform architecture using the platform
    US9811663B2|2017-11-07|Generic unpacking of applications for malware detection
    US20080196004A1|2008-08-14|Apparatus and method for developing component-based software
    US20060235664A1|2006-10-19|Model-based capacity planning
    US20050198628A1|2005-09-08|Creating a platform specific software image
    CN103493028A|2014-01-01|Virtual disk storage techniques
    US8457944B2|2013-06-04|Method and device for determining requirement parameters of at least one physical hardware unit
    US10003514B2|2018-06-19|Method and system for determining a deployment of applications
    Schoofs et al.2009|An integrated modular avionics development environment
    US8140899B2|2012-03-20|Method and system for diagnosing a computer system
    BE1018147A5|2010-06-01|BRIDGE PROGRAM, BRIDGE METHOD, AND SIMULATOR.
    JP6089064B2|2017-03-01|Method, computer system and memory device for updating software components
    Castellanos Ardila et al.2020|Separation of concerns in process compliance checking: Divide-and-conquer
    Macher et al.2014|Bridging Automotive Systems, Safety and Software Engineering with a Seamless Toolchain
    US20190147131A1|2019-05-16|Ecu simulation device
    US20080319815A1|2008-12-25|Computer-implemented method, system, and program product for conducting a trade-off study
    Hatcliff et al.2021|HAMR: An AADL Multi-platform Code Generation Toolset
    US8055733B2|2011-11-08|Method, apparatus, and computer program product for implementing importation and converging system definitions during planning phase for logical partition | systems
    Pilipchuk et al.2018|Aligning business process access control policies with enterprise architecture
    US20190294155A1|2019-09-26|Method, device and system for replaying movement of robot
    同族专利:
    公开号 | 公开日
    US20080288232A1|2008-11-20|
    CN101308522A|2008-11-19|
    JP2008287308A|2008-11-27|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US5479355A|1993-09-14|1995-12-26|Hyduke; Stanley M.|System and method for a closed loop operation of schematic designs with electrical hardware|
    JPH11238004A|1998-02-20|1999-08-31|Ricoh Co Ltd|System simulator|
    JP3189793B2|1998-07-17|2001-07-16|日本電気株式会社|System simulator and system simulation method|
    JP2000259445A|1999-03-05|2000-09-22|Nec Corp|Cooperative software/hardware simulation method|
    US6993469B1|2000-06-02|2006-01-31|Arm Limited|Method and apparatus for unified simulation|
    JP4287624B2|2001-07-19|2009-07-01|パナソニック株式会社|Bus simulation device, bus simulation program|
    US7412588B2|2003-07-25|2008-08-12|International Business Machines Corporation|Network processor system on chip with bridge coupling protocol converting multiprocessor macro core local bus to peripheral interfaces coupled system bus|
    JP2005339029A|2004-05-25|2005-12-08|Canon Inc|Program cooperation system|JP5450271B2|2010-06-10|2014-03-26|株式会社東芝|Simulation apparatus, simulation program and method|
    法律状态:
    2019-01-30| MM| Lapsed because of non-payment of the annual fee|Effective date: 20180531 |
    优先权:
    申请号 | 申请日 | 专利标题
    JP2007128771|2007-05-15|
    JP2007128771A|JP2008287308A|2007-05-15|2007-05-15|Bridge program, bridge method and simulator|
    [返回顶部]